A variety of electronic devices apply programmable control means, such as microprocessors, microcontrollers, programmable logics, and/or application-specific programmable integrated circuits. Such electronic devices contain stored software consisting of one or more programs containing e.g. program commands required for the operation of the electronic device. In the storage of such software, a memory is used, of which at least a part is a non-volatile memory, i.e. the content of the memory is retained even if the operating voltage of the memory is cut off. These memories include for example a read-only memory (ROM), a programmable ROM (PROM) and an electrically erasable PROM (EEPROM). At least a part of the memory is normally integrated in the electronic device, but in addition, the memory can be increased in many applications by means of, for example, a memory expansion board, or by using a storage means outside the device, such as a data network or the like. One such memory expansion board is the so-called Flash memory card. The Flash memory is a kind of EEPROM type memory whose content can be changed by electrical programming. The contents of the Flash memory will be retained even after the cutting off of the operating voltages. By means of such an expansion memory, it is easy to provide the electronic device with new software, memory capacity for storing, for example, photographs in a digital camera, for setting access rights e.g. in a mobile station, etc. The installation of software in an electronic device can also be performed, in a way known as such, by using other storage means, such as a diskette, a CD-ROM, or a DVD, or possibly directly from a data network.
To run a program, it is typically loaded in the memory of the electronic device, after which the processor of the electronic device starts to run the program code, preferably under control by the operating system. In multi-run operating systems, the operating system alternates the processing of different programs being run, wherein each program being run is typically processed for a given time, after which another program is in turn for processing. The processing time allocated for different programs may vary. If there are several processors, it is possible to process several processing threads in parallel.
The programs may consist of one or more program blocks which are preferably stored as files of their own in a permanent memory, for example on a diskette, a fixed disk, a Flash memory, a data network, or the like. Furthermore, so-called library programs are known, to which several different programs or only one program can have access, wherein the program code may comprise a call to a library program. During the running of a program, the processing is, for a moment, shifted to the library program, after which the processing is continued from the program, which is called the library program. Such library programs typically include programs of general use to implement, for example, the displaying of data on the display of the electronic device. Thus, the compiler of the program does not need to compile the commands needed for controlling the display in the program, but it is possible to define a call to a library program in the program and, in connection with the call, to determine the parameters possibly needed by the library program.
Some electronic devices, such as computers and wireless communication devices, are used more than before to perform such operations, in which the programs used must be reliable. Such operations include, for example, the attending of bank errands, such as the payment of bills, the subscription of products and/or services, the transmission of confidential data in encrypted form, signing, etc. In this context, reliability means, for example, that the programs must not contain an unreliable program code, such as so-called viruses, which might alter the running of the program. A virus or another unreliable program may change the processing of the program without the user noticing anything different from the normal. Thus, for example in a situation, in which the user wants to make a payment, for example to pay the licence of a music piece subscribed via the network, the user starts a program intended for making payments in the electronic device. The program or a library program used by the program may be affected by a virus, wherein the operation of the program no longer corresponds to the original. On the other hand, there are virus programs which may affect the operation of other programs to be run in electronic devices without altering a part in the program related to the payment event or the library program. The virus may thus be activated somewhere in a program being processed in the so-called background, such as in a calendar application. In said payment event, the virus program may, for example, wait until the payment program writes the sum to be paid on the display of the electronic device, and upon detecting this, reduces the sum to be displayed, changes the recipient of the payment, or the like. However, the amount of the original sum is debited from the user's account, although the user believes that the charge was lower and was forwarded to the correct recipient of the payment.
A solution has been developed to the above-presented problem, where known signs of virus programs, or so-called fingerprints, are searched for in the memory of the electronic device. These fingerprints are a kind of parts of the program code, which are typical for a given virus program or a virus program type. However, the number of virus programs is already so large that it is almost impossible to search for all virus programs on the basis of such fingerprint identification. Furthermore, the method requires that the fingerprint data are updated in the electronic device as often as possible, even several times a day, to keep the data as up-to-date as possible.
Another solution is that for each program to be installed in the electronic device, a check digit is computed by a suitable algorithm, such as a cryptographically strong hash algorithm. In the computing of such a hash algorithm, the program code of the program is used. The check digit is stored in the electronic device in connection with the installation of the program. The storing must take place in such a way that it is made sure that the check digit cannot be changed. In connection with the starting of the program, the check digit is compared with a reference digit computed for the program in a corresponding way. If the check digit and the reference digit are the same, it is assumed that the program is reliable, and the program is loaded in the memory of the electronic device and the running of the program is started. However, in practice, there will be situations in which the checking performed at the stage of loading the program will not be sufficient. For example, even several months may have passed since the loading of the program before the checking is made. Thus, the reliability of the software loaded in the memory also should be checked. This checking is necessary in connection with starting of e.g. a payment program or another such program, for whose reliable operation it is absolutely important that there are no unreliable programs in the memory of the electronic device. To check the reliability of a program loaded in the memory, it is usually not possible to use said computing of the reference digit. This is due to the fact that the program normally contains such parts of the program code whose content must be changed in connection with the loading according to the part of the memory where the program is loaded at the time. Such variable parts include, for example, the memory addresses, the absolute jump addresses and links in the program. Thus, the computation of the reference digit will no longer give the same result, so that even though the program was not changed to be unreliable, the comparison between the check digit and the reference digit will not give the same result.